home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0435.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  4.8 KB  |  133 lines
  1.  
  2. >Perhaps we should have all three.
  3.  
  4. >I understand that these are the only SGML-conformant combinations.  Is
  5. >this too much of a mess?
  6.  
  7. I think so. The processing should be broken into two parts: SGML parsing,
  8. and application processing. The significance of newlines is an application
  9. issue: the SGML parser never throws out newlines in data (it does throw
  10. out newlines between tags and in some other places that I don't fully
  11. understand).
  12.  
  13. These are the choices for SGML parsing:
  14.  
  15.     CDATA        all characters treated as data.
  16.             Terminated by </A where A is any letter.
  17.     RCDATA        characters and entities only. &entity; recognized.
  18.             Terminated by </A as above
  19.     mixed content    tags and #PCDATA.
  20.             Tags, entity references, comments, etc. recognized.
  21.             The pattern of tags and data is regulated
  22.             by the element declaration.
  23.     element content    tags only. Pattern of tags is regulated.
  24.     ANY        like mixed content, but tags aren't regulated
  25.  
  26. CDATA is simplest to process, but you can't do things like
  27.  
  28.     char* any_string;
  29.     printf("<XMP>%s</XMP>", any_string);
  30.  
  31. because any_string might contain </A, and you're screwed.
  32.  
  33. RCDATA is capable of the above construct, but at a cost:
  34.  
  35.     char* any_string;
  36.     char* rcdata = HTML_replace_specials(any_string);
  37.     printf("<XMP>%s</XMP>", rcdata);
  38.     free(rcdata);
  39.  
  40. where HTML_replace_specials changes '<' to < (to prevent </A), '>' to >
  41. (to prevent ]]>, the marked-section close delimiter. Ugh!), and
  42. '&' to & (to prevent &xxx from being mistaken for an entity reference).
  43.  
  44. But if you're going to go to that trouble, you might as well
  45. use mixed content. That's why I changed my mind about using RCDATA
  46. for XMP and LISTING elements.
  47.  
  48. My current DTD only uses element content (for the HTML document element*),
  49. CDATA (for XMP and LISTING) and mixed content (for everything else).
  50.  
  51. As to your suggestions...
  52.  
  53. ><XMP>        newlines significant        no anchors    CDATA
  54.  
  55. This is already supported, except that most implementations don't
  56. quite parse CDATA correctly. The "newlines significant" isn't a
  57. parsing issue. It's an issue of how the application processes character
  58. data. Let's call this mode of application processing where the
  59. characters are written to the screen as-is, rather than
  60. typeset into paragraphs TYPEWRITER mode. We'll call the default TYPESET mode.
  61.  
  62. ><PRE>        newlines significant        no anchors    RCDATA
  63.  
  64. The only implementation of the PRE tag that I know of looks more like:
  65.  
  66. <PRE>        newlines significant        anchors        PCDATA
  67.  
  68. It's actually pretty clean: you use
  69. mixed content SGML parsing, and TYPEWRITER application processing.
  70. So I changed the name to TYPEWRITER, for no good reason, really.
  71.  
  72. The newlines significant/no anchors/RCDATA is what I suggested for
  73. XMP and LISTING, so they could contain any string. But since current
  74. implementations don't process entities in these elements, it's
  75. not worth it.
  76.  
  77. ><FIXED>        newlines not significant     anchors        PCDATA
  78.  
  79. This introduces a third application mode besides RAW and TYPESET:
  80. it's kinda like RAW, but you toss the newlines, and start a newline
  81. at every <P> tag. I don't like it.
  82.  
  83. >Tony, can you make a similar patch for <fixed> as above for Midas?
  84.  
  85. You could, but it doesn't fit neatly into the current architecture.
  86. Tony wrote one widget to do TYPESET processing (SGMLCompoundText)
  87. and one to do TYPEWRITER processing (SGMLPlainText). The FIXED
  88. widget calls for a new widget, or a modification of SGMLPlainText
  89. to ignore newlines in some cases. (You can't just use the SGMLCompoundText
  90. with a fixed-width font, because it compresses whitespace.)
  91.  
  92. >I have put Dan's new spec (which contains <typewriter> -- what's going on,  
  93. >Dan?!) in the web at  
  94. >http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/MarkUp.html with a link from
  95. >the current spec.
  96.  
  97. Thanks.
  98.  
  99. >  The DTD was not in the tar file, so Dan's previous one is  
  100. >linked in. This includes all Dan's test HTML.
  101.  
  102. Ack! I think the DTD is pretty important. I'll get the new
  103. one there ASAP. I highly suggest that _all_ data providers grab the DTD
  104. and the sgmls parser and try validating samples of the data they're
  105. serving up. It's the quickest and surest way to check for compliance.
  106. I need to write a section for data providers in the spec.
  107.  
  108. >I would like to include <HEADER> and <BODY> tags too.
  109.  
  110. * I wrestled with this at great length to come up with a DTD
  111. lends _some_ structure to HTML wihthout clashing badly with
  112. existing data.
  113.  
  114. The document element declaration is:
  115. <!ELEMENT HTML O O  ((TITLE? & NEXTID? & ISINDEX?), BODY)>
  116.  
  117. The O O means the HTML start and end tags can be omitted.
  118. They'll be inferred by the parser. Since there's no #PCDATA
  119. in the content model, it has element content, so that
  120. whitespace between tags is thrown out.
  121.  
  122. The TITLE, NEXTID, and ISINDEX can come in any order, and
  123. they can are optional, but they can appear at most once,
  124. and they have to be before the BODY.
  125.  
  126. I made the <BODY> tags minimizable so current
  127. HTML is legal. I couldn't seem to work in a HEADER
  128. element the same way.
  129.  
  130. Dan
  131.  
  132.  
  133.